REMARKS 



INTRODUCTION 

Claims 1 -1 5, 20, 23-25, and 27-29 were previously and are currently pending and 
under consideration. 

Claims 1 -1 5, 20, 23-25, and 27-29 stand rejected. 
Claims 1 and 1 0 are amended herein. 
No new matter has been added. 

Claim 1 : He Does Not Teach Measuring Network Latency of Client From Physical Proximity of 
Client to Globally-Dispersed Servers 

Amended claim 1 recites "one of a plurality of load balancing domain name servers 
(DNS-LBs) deployed in a physical proximity from which the actual network latency of the clients 
to the globally-dispersed servers may be measured ... the DNS-LB using its measurements of 
actual network latency from the clients to the globally-dispersed servers to resolve the DNS 
lookup requests to respective IP addresses of the some of the globally-dispersed servers". In 
other words, the DNS-LB is in physical proximity to the clients such that the DNS-LB itself can 
measure network latency that a client would approximately experience communicating with 
server. Notably, the DNS-LB itself measures the network latency to the servers, and because 
the DNS-LB is in proximity to the clients, the DNS-LB has an accurate estimate of the latency 
the clients would experience if they communicated with the servers. 

The rejection notes that "He et al fails to teach wherein the DNS are placed in physical 
proximity producing network latency similar to the clients" (Office Action, page 4, line 8). The 
rejection cites Zisapel as teaching this feature at paragraphs [0036] - [0038]. 

However, Zisapel cannot teach the noted feature because the load balancing servers in 

Zisapel (LB1 , LB2, LB3) are not in proximity to the client 26. Intuitively, every figure of Zisapel 

shows the client 26 removed and apart from the load balancing servers LB1 , LB2, and LB3. In 
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every case, the client 26 and the load balancing servers are separated by the network/Internet 
1 4. The load balancing servers of Zisapel are not near the client 26. If they were, it would not 
make any sense for the load balancing servers to send polling requests 58 to the client 26 (see 
Figure 2C), because latency between client 26 and load balancing servers would be negligible if 
they were physically proximate (or if they were able to measure similar latency as what would 
be experienced by the client 26). 

The rejection cites paragraphs [0036] - [0038]. However, nothing in these paragraphs 
suggests this above-mentioned feature of claim 1 . Paragraph [0036] discusses that when client 
26 directs a request to LB1 and LBTs servers SI ... Sn are unavailable, LB1 effectively redirects 
the client's request (using IP address substitution) to LB2. Paragraph [0037] is an overview of 
Figures 2A-2F. Paragraph [0038] only discusses LB1 's proximity table 54. The proximity table 
54, which indicates "subnets and the best server farm site or sites to which requests from a 
particular subnet should be routed". Paragraph [0038] does mention that how the "best" site is 
determined is described later. However, as seen in Figures 2A-2F, the load balancing servers 
measure network latency from the load balancing servers to the client 26. In contrast, claim 1 
recites the DNS-LB measuring latency not from itself to the clients, but rather from the clients 
to the globally-dispersed servers. 

Measuring latency from node A to node B is much different than measuring latency from 
node B to node A. It is well known in the field of IP routing that routing is not symmetric. That 
is, the route from node A to node B can be much different than the route from node B to node 
A. The latency from a client to a server might involve a local or nearby bottleneck which the 
server communicating to the client might not experience (e.g., its route avoids the bottleneck 
or may have a static route that bypasses the bottleneck). Many other scenarios are possible 
where a routing path in one direction is much different, and is faster or slower, than a routing 
path in the other direction. 

Claim 10 
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Claim 1 0 recites "a DNS-LB located in a physical proximity from which the actual 
network latency from the clients to the globally-dispersed servers is measured by the DNS-LB 
from a location physically proximate to the ISP's point of presence" and "determining of client- 
to-server latency performance". As discussed above with reference to claim 1 , He does not 
discuss a LB server measuring network latency, and He's LB servers (LB1-LB3) measure latency 
to a client 26, not to a server SI ...Sn. Furthermore, Zisapel measures latency from a LB server 
to a client 26, which does not provide " client-to-servei" latency. 

Withdrawal of the rejection is respectfully requested. 

Claim 12: He-Zisapel Does Not Monitor Performance By DNS-LB Transmitting Communications 
to the Servers 

Claim 12 recites "monitoring performance of the servers at the received IP addresses by 
the DNS-LB transmitting communications to the IP addresses of the servers". The rejection 
cites He, col. 4, lines 5-24, and col. 6, lines 30-67. However, He only discusses the LB (load 
balancing) server "examining the network load measurements ... to select the most optimal 
server for the client request" (col. 4, lines 22-24). Nowhere does He indicate that the LB itself 
communicates with the servers to monitor their performance. He states only that the "network 
measurements [are] gathered" (col. 3, line 8). 

The other portion of He cited by the Examiner (col. 6, lines 30-67) discuss only the flow 
for server resolution. This portion of He has no mention of an LB server monitoring 
performance by transmitting communications to the IP address of a server being balanced. The 
only communication from the LB server discussed in this portion of He is that of the LB server 
sending an IP address to the client that initiated a request. This portion of He does mention the 
LB server selecting a server based on predetermined criteria (step 253). However, the only 
criteria mentioned by He (network traffic, number of client request) are measurements purely 
local to the server being balanced itself. Therefore, He does not teach monitoring performance 
by transmitting from an LB server to a server being balanced. 
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Withdrawal of the rejection is respectfully requested. 

Should the rejection be maintained, Applicant respectfully requests clarification of the 
rejection. In particular Applicant requests the Examiner to explain where it is believed that He's 
LB server sends communications to the IP address of any of servers Serverl ... ServerN or 
Server2 ... ServerM (see Figure 1). 

Claim 20: He's LB Server Does Not Monitor Performance of Servers 

Claim 20 recites "deploying a plurality of load balancing domain name servers (DNS-LBs) 
in a physical proximity from which the actual network latency of the clients connecting to the 
ISP POPs may be measured". The rejection cites only He. However, He has no mention of 
clients connecting to ISP POPs. Applicant respectfully notes that a point-of-presence (POP) is a 
particular term of art well known in the field. 

Withdrawal of the rejection is respectfully requested. 

Should the rejection be maintained, Applicant respectfully requests explanation of where 
He or Zisapel teach an ISP POP. 

Claim 23: Zisapel Measures Latency from LB Server To Client, Not To Content Server 

Claim 23 recites "the identified load balancing server measuring network latency from 

the load balancing servers to the content servers". The rejection cites Zisapel, paragraphs 

[0040] - [0042]. However, the cited portion of Zisapel notes that "[t]o determine comparative 

network proximity, LBI, LB2, and LB3 preferably each send a polling request 58 to client 26 

using known polling mechanisms" (emphasis added, para. [0040], lines 6-10). This is also 

shown in Figure 2C, where LBI -LB3 send "POLLING REQUEST" 58 to client 26 , not to the servers 

SI ...Sn. Figure 2D shows client 26 returning "POLLING RESPONSES" 60. To summarize, Zisapel 

discusses measuring network latency from a load balancing server to a client, not "from the 

load balancing servers to the content servers" as recited in claim 23. Measuring latency from a 

LB server to a client is distinctly different than measuring latency from a LB server to a content 

Microsoft Corporation 
Application No.: 09/714,406 
Filed: Nov 16, 2000 

Page 1 3 of 1 7 



server (note that in Figure 2D of Zisapel, the LB servers do not even use network/Internet 14 to 
communicate with their respective content servers SI ...Sn). 

Applicant also notes that, as explained above, latency is direction-sensitive, and so an 
LB server polling client 26 is not the same as a device proximate to the client 26 (e.g., an LB 
server proximate to the client 26) communicating to a content server. 

Withdrawal of the rejection is respectfully requested. 

Claim 28 

Claim 28 recites "measuring network latency from the DNS-LB to the servers that 
correspond to the hostname in the request by repeatedly sending communications from the 
DNS-LB to the servers". The rejection notes that He does not discuss this feature, and cites 
paragraphs [0036H0038] of Zisapel. However, as explained above, Zisapel's LB servers (LB1 - 
LB3) poll the client 26 , not the serves that are being load balanced. 

Claim 29: Incomplete Examination 

Claim 29 recites "where the IP address corresponding to the hostname was selected by 
the DNS-LB based on network measurements obtained by repeated transmissions from the 
DNS-LB to IP addresses that correspond to the hostname". The rejection does not address this 
feature. However, in addressing other claims, the Examiner has indicated that He does not 
discuss this feature, and as noted above, Zisapel's LB servers measure by communicating to the 
client 26, not the IP addresses of the servers being balanced. 

Claim 29 also recites "receiving a referral to an authoritative DNS server (DNS-A) that 
corresponds to the hostname". The rejection does not address this feature. 

Withdrawal of the rejection is respectfully requested. 

Claims 1 . 10. 12. 20. 23.28. and 29: He Does Not Reply With Load Balanced Resolved IP 
Address Of Hosname Being Looked Up 
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The independent claims recite various features by which a client's DNS lookup request 
(or the like) is actually resolved to a balanced IP address of the hostname. That is, the request 
is for a hostname's IP address, and the system returns a load balanced IP address for the 
hostname. He discusses a generic balancing system where a client's DNS request, if not 
answered by its client DNS system 45, is answered with the address of another DNS server 
which the client can use to again try to resolve the hostname. Note that columns 1 -4 of He 
describe a complete balancing system without reference to DNS; DNS is described as only one 
type of service that can be balanced using the same generic system described in columns 1 -4. 

Also, as noted in columns 5-6, when the client's main DNS service point (DNS client 
system 45) cannot resolve the client's request, the system "provides an IP number to the client 
system 43. Using the provided IP number, the client system directs its request to that number" 
(col. 6, lines 1-4). The only "its [client's] request" mentioned is the client's DNS lookup request 
itself (see, e.g., col. 5, lines 1 -6 and 47). Thus, when DNS client 45 cannot resolve a client 
lookup request, He does not return an address for the requested hostname, rather it returns an 
IP address of another DNS server (akin to a redirect) which the client then uses to again request 
a name lookup. In sum, when system 45 cannot resolve the client's request, it returns the 
address of a DNS server, which is not the IP address of the requested hostname. 

Withdrawal of the rejection is respectfully requested. 

Claims 1 . 1 0. 1 2. 20. 23. 28. and 29: No Prima Facie Case of Obviousness 

Recent developments in case law and PTO policy have made it clear that when a 

combination is offered by an Examiner, the Examiner must explain the reasoning and factual 

underpinning for making the proposed combination. The present rejection is traversed because 

the reason for the combination, for each of claims 1, 10, 12, 20, 23, 28, and 29 is only "in 

order indicate subnets and the best server farm site or sites to which requests from a particular 

subnet should be routed". The rejection does not explain why this would be desirable in He or 

what deficiency or problem of He this would solve. The rejection does not explain how the 

Microsoft Corporation 
Application No.: 09/714,406 
Filed: Nov 16, 2000 

Page 1 5 of 1 7 



offered motive would improve He. In fact, He already has a mechanism to pick a site for a 
request, so the addition of Zisapel appears redundant or superfluous. 

Finally, the offered motive of allowing a load balancing server "to indicate subnets and 
the best server farms site or sites to which request from a particular subnet should be routed" 
appears to be incompatible with He. He performs load balancing by measuring actual load 
(e.g., CPU usage) of the servers being balanced. He does not take into account network 
performance or latency. Therefore, it does not matter what subnet a client is on, or even where 
its network location is. All that matters in He is how heavily loaded the servers are. 

Withdrawal of the rejection is respectfully requested. 

REQUEST FOR SPECIFIC REPLY TO ARGUMENTS PRESENTED ABOVE 

Applicant respectfully requests that each separate argument above be addressed by the 
Examiner, as this may help the Applicant to evaluate the possible merits of the arguments 
should the present Application become ripe for appeal. 
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CONCLUSION 

The present application is in condition for allowance. A prompt action to such end is 
requested. 

Should any fees be required in connection with this document, the Commissioner is 
authorized to charge those fees to Deposit Account No. 50-0463. 

If the Examiner believes a telephone interview would be helpful to expedite prosecution, 
the Examiner is invited to contact Applicant's undersigned representative at the telephone 
number below. 

Respectfully submitted, 
Microsoft Corporation 

Date: 28 May 2008 By: /lames T. Strom/ 

James T. Strom, Reg. No.: 48,702 

Attorney for Applicants 

Direct telephone 425-939-0781 
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